1. Field of the Invention
The present general inventive concept relates generally to the field of electronic circuit design and manufacturing, and more particularly relates to an electronic design automation (EDA) system to edit and save changes to cells of an electronic circuit design.
2. Description of the Related Art
Circuit designers can create a custom design of integrated circuits, printed-circuit boards, and other electronic circuit systems using electronic design automation (EDA) technologies that typically run on an operating system in conjunction with a microprocessor-based computer system or other programmable control system. For analog, RF, and mixed signal design applications, the EDA software allows a user to implement “cells” as a basic element of functionality through a layout editor implemented on a graphical user interface. A given cell may be placed, or “instanced,” many times in a layout design to accelerate the design process. In a parameterized cell (pcell), a designer may select and modify certain design parameters to define desired operational features and physical properties of selected electronic components in a particular design application, for example, an integrated circuit (IC). A pcell is typically more flexible than a non-parameterized cell (non pcell) because different instances of the pcell may have different parameter values. For example, with a transistor pcell, the length, width, number of gate segments, and/or other design elements of the transistor, can be realized by simply inserting or changing one or more parameter values. Rather than have many different cell definitions to represent the variously sized transistors in a given design, a single pcell may take a transistor's dimensions (e.g., width and length) as parameters. Different instances of a single pcell can then represent transistors of different sizes, but otherwise similar characteristics.
Conventionally, a parameterized cell or pcell exists at three different levels: superMaster, subMaster, and instance. The superMaster typically resides in a computer readable medium, such as a disk, and consists of program code, parameter definitions and default values. The subMaster, which receives properties from an associated superMaster, typically resides in virtual memory, and contains unique geometries produced by a unique set of parameter values. The instance, which inherit parameters and content from an associated subMaster by means of being bound to that subMaster, also typically resides in virtual memory.
Those skilled in the art will appreciate that the term “subMaster” means a cell master created by evaluating pcell code associated with the superMaster, for a given unique set of parameter values. Traditionally superMasters have a disk representation, have associated parameter definitions, and code associated with them. subMasters are traditionally created in-memory (i.e., volatile memory), on demand, for each unique set of parameters associated with instances in the open design. subMasters are traditionally stored in-memory, not disk, and are traditionally not edited by the user. Attempts have been made to allow subMasters to be stored on disk, for faster opening of designs, but existing approaches do not permit editing of subMaster content in layout editors.
The actual shapes that comprise the subMasters are typically created by a function associated with the pcell, usually written in a programming language such as SKILL, for example. The EDA system can then automatically generate multiple representations of the electronic components of the pcell based on the assigned parameters.
Traditional EDA systems fill, or assign, the content of a pcell subMaster according to its pcell parameters by executing the pcell code. The resulting pcell subMaster contents produced by the pcell program code are considered as correct by definition. Typically, if an instance is bound to this subMaster, an instance parameter changes, and the instance's master is requested by the EDA system (for example to draw the instance), the EDA system automatically searches in memory for an existing pcell subMaster with parameters matching the new set of parameters, and on failure to find such a subMaster, triggers a recomputation of a new pcell subMaster with the new set of parameters, by executing the pcell code, and binds the instance to that new subMaster. The pcell can then be viewed from different levels in the design hierarchy as a cell instance of the overall circuit design.
Design hierarchy refers to an electronic circuit design having a collection of different levels (e.g., level 0, 1, 2, . . . , n), wherein each higher level hides the details and shapes of the lower levels to simplify the design process. That is, a design hierarchy allows the circuit design to be broken down into a collection of smaller designs (or levels), thus reducing visual complexity of the design process, and enabling the EDA system to work with a collection of smaller design files so the design tools can run faster. In contrast, flat design files (i.e., no design hierarchy) are typically very large since all of the details are included in the same level, thus increasing the visual complexity of the design and causing the design tools to run more slowly. Existing approaches which attempt to make local edits in a hierarchical layout design while retaining design hierarchy typically involve modifying parameters on instances at level n in order to initiate a re-computation of the pcell sub-master bound to that instance. Such parameter modification can be initiated either graphically, for example, by clicking and dragging the boundaries of a cell to change the size of a cell (e.g., stretching stretch handles) or by dragging one cell to adjoin another cell (e.g., abutment), or by modifying parameter values on the instance directly, for example, by using a property editor or other editing interface to view and edit the parameter values of a cell. One drawback of existing approaches is that although they may allow a user to modify pcell parameters through stretching stretch handles and abutment, they are less than satisfactory in allowing other edits since the contents of the new sub-master are limited to what the pcell programming code is capable of generating, and is controlled by parameter modifications on the instance, with results being that only the edits that the pcell designer has built into the pcell programming code can be made. In other words, free editing of the contents of a pcell sub-master to form another pcell subMaster is not currently available. To work around this limitation, users sometimes flatten the pcell instances throughout the layout design, but this results in losing the design hierarchy and increasing memory usage. Accordingly, existing approaches do not enable a user to easily and efficiently make local edits of masters of instances in hierarchical designs without losing the hierarchical structure of the design, and do not allow editing of subMaster content of selected instances, to form new subMasters with different parameters, which can then be saved to disk.
Another drawback of existing approaches is that they do not allow the retention of user edits to shapes during automatic parameter modifications such as auto-abutment and stretching stretch handles. For example, in existing approaches, users are unable to retain their edits during pcell abutment or after user-initiated changes of parameters of instances whose masters have been edited. Another drawback of the existing approaches is that in order to make edits to one particular instance of a pcell the user must manually save a copy of the pcell master, apply their edits in the non pcell copy cellview, and then manually re-master the one instance that they wish to be affected to the new non pcell cell view they created. Users must do this to ensure that other instances of the same master are not affected by the edit.
Moreover, existing approaches to cell editing do not provide the ability to easily make a local edit to a single instance of a non-pcell master, if there are multiple instances of that master in the design because such edits of an existing master affect all instances. Instead, in order to make local edits to a non-pcell master of one instance of a non-pcell design, a user must undertake the manual, time-consuming process of saving a copy of the non-pcell sub-design, applying the local edits, and then manually re-mastering the instance to the copy design containing the edits. Such limited editing capabilities of these and similar existing approaches has become a serious problem for customers, who do not want to be constrained to only those edits that the process design kit (PDK) designer has built into the respective design cell offerings. PDKs typically include an assortment of component libraries, cells, technology files, and physical verification files to improve design capabilities and data flow, and offer the user a limited range of validated components and design automation features to speed the design process, and to support the physical implantation of the custom design with full chip integration, silicon analysis features, and full chip integration support.